In a previous post, I discussed “Security through Obscurity” and briefly touched on the concept of SNOW.Here we’ll look a little deeper at SNOW and showcase some of the work I have done with it.Some technical back-story on SNOW:I think the original author’s website says it best. . .Whitespace SteganographyThe encoding scheme used by snow relies on the fact that spaces and tabs (known as whitespace), when appearing at the end of lines, are invisible when displayed in pretty well all text viewing programs. This allows messages to be hidden in ASCII text without affecting the text’s visual representation. And since trailing spaces and tabs occasionally occur naturally, their existence should not be sufficient to immediately alert an observer who stumbles across them.The snow program runs in two modes - message concealment, and message extraction. During concealment, the following steps are taken.Message -> optional compression -> optional encryption -> concealment in textExtraction reverses the process.Extract data from text -> optional decryption -> optional uncompression -> messageEach of the steps are described in detail below.CompressionThe compression scheme used by snow is a fairly rudimentary Huffman encoding scheme, where the tables are optimised for English text. This was chosen because the whitespace encoding scheme provides very limited storage space in some situations, and a compression algorithm with low overhead was needed. In other words, short messages had to compress to even shorter data. Depending on the text, you can usually get 25 - 40% compression.If you want to compress a long message, or one not containing standard text, you would be better off compressing the message externally with a specialized compression program, and bypassing snow’s optional compression step. This usually results in a better compression ratio.EncryptionThe encryption algorithm built in to snow is ICE, a 64-bit block cipher also designed by the author of snow. It runs in 1-bit cipher-feedback (CFB) mode, which although inefficient (requiring a full 64-bit encryption for each bit of output), provides the best possible security when different messages are encrypted with the same password. Although using the same password many times is theoretically a big no-no, in the real world it often can’t be avoided.The lower 7 bits of each character in the password are packed into an array, which is used to set the encryption key. The ICE encryption algorithm can operate at different levels, with higher levels using longer keys and providing more security. The ICE level appropriate for the password length is used.CFB mode makes use of an initialization vector (IV), which is initially set to the first 64 bits of the key encrypted by itself. Each time a bit is encrypted, the IV is encrypted, and the leftmost bit of the encrypted IV is XORed with the bit. The IV is then shifted left one bit, and the ciphertext bit is added to the right. Decryption reverses this process.My dream. . .One of the first applications for SNOW that was described to me was for HTML files. Most people never look at the source code for a webpage, and when they do, they are often greeted by VERY large files filled with code that only developers (and sometimes only the one who built it) understand.My professor joked that “there could be a whole network of spies out there using this on the internet right now for all we know."Though fascinated by the technology, I found it odd that one would have to use a command line program to decrypt. Users would first have to know exactly which webpage has a secret message. They would then have to manually download the source, run the program on the command line, and follow this process for each password they wish to try.I settled on a fairly simple vision: Let web browsers detect and attempt to decrypt hidden messages automatically while the user browses the web…without thinking and with minimal effort.I later found a more innovative question: What if the hidden message was HTML code? Could we somehow re-render the webpage and display a website that only certain users are supposed to see? What if this could serve as the beginning foundation for a new layer of web security?Taking it further. . .A lot of tools had already been created for SNOW. In addition to the original command line version, an applet and CGI versions were also created.But all of these tools assume that you want to encrypt/decrypt a file and all of the original code is based around command line interaction. So I started with the Java version of SNOW, created a generic interface that takes a URL (instead of a file) in addition to other parameters and then created a JAR file that anyone could incorporate into a development project.Having a JAR file was important as I had already decided that I wanted to build a SNOW based Firefox extension. Although not a standard part of Firefox extension development, several tools already existed for calling JAR files from plugin code.With the Java end of things complete, I next focused on building a Firefox extension (version 3.6). The basics of a extension were very easy, just some JavaScript and XUL (an XML type language used by Firefox) code. The hard parts were making calls to the JAR file and getting the UI to look just the way I wanted. Some screen shots are below.The state of things today:I was in the long process of getting the extension officially approved by Mozilla, but in the middle of things they changed some of their quality standards. By the time I got around to taking another look, they had upgraded a couple of versions and there was talk of all extensions being moved to HTML5. As a result, you can’t really use the extension unless you have Firefox 3.6 and install in manually.If you would like to install it though, you can download a copy here. That page also has a secret message embedded in the source code so you can test that it’s working properly. (I think the password is “ice”) If you install it correctly and give it the proper password, the webpage itself actually changes. (See screenshots below) You can also find a copy of the detailed report I wrote.The future:The extension itself is a little resource heavy (in my opinion). It also produces some false positives (a good thing?) and isn’t as smart as it could be. So there is some polish that needs to be done. In addition, I’d like to get it working with newer browsers and have it as an officially approved install.I plan to explore the use of snow with authentication tokens assigned to users by a given website. Also, for developers, I want to create a command line program to “snowstorm” their website. The developer will feed it the path to their source code and the program fills every file with random, useless snow. Then, the developer can pick individual files to put a real message into. Suddenly, it becomes a lot harder to know which web pages have snow and which don’t.Beyond these basic ideas, there are a LOT of ideas I have for taking this concept to the next level and actually making it a useful tool that people would want to leverage as a potentially new layer of web security.